feat(compiler): Add grpc support for Swift - #3776

Before writing Swift output, check that no two schemas or services claim the
same file path or top-level symbol. A service named after a generated type, or
a duplicate service, now fails fast with a clear message instead of emitting
Swift that will not compile.

Exercise the Swift companion across the four streaming shapes, keyword-escaped
methods, imported request and response types, the default package, both IDL
frontends, and the collision preflight, so the emitter and its symbol names stay
pinned.

Generate a two-package schema, then swift build and run a SwiftPM package on
grpc-swift and local Fory that hosts the generated provider and round-trips all
four streaming shapes across the import boundary. Skipped when swift is absent.

Wire Swift into the shared gRPC generation step so the interop schemas emit
Swift companions alongside the other targets.

Add a Swift gRPC guide covering dependencies, server and client usage, streaming,
and troubleshooting, link it from the Swift guide index, and note the Swift
companion in the compiler guide and agent rules.

Break the streaming handler closures across lines so generated companions stay
under the swiftlint line-length limit even with long package-qualified names.

Put handler braces on the declaration line, give each async parameter its own
aligned line, name the unwrapped stream value, and scope a type_name disable
around the package-prefixed symbols so swiftlint reports no violations.

Schemas that share a top-level package component make the model generator emit a
duplicate root enum, which the Swift compiler rejects in one module. Pin it with
a strict xfail fixture and a docs note pointing at disjoint packages.

The Swift Fory instance is single-threaded, but gRPC drives the marshaller from
many threads at once, so sharing one instance races. Build one Fory per thread
from the module config and registrations, and fire 200 parallel calls in the
fixture to exercise it.

Record that the generated client is async only and that interceptors are not
emitted, both because grpc-swift types them on the internal Fory wrapper, and
describe the per-thread marshalling.

Name the wire wrapper per service so it is reachable, then drive it from 2000
parallel threads under ThreadSanitizer, asserting no data race and that the
per-thread Fory stays wire-compatible with the module's shared instance. Against
a shared instance TSan flags a race in the type resolver.

The ThreadSanitizer build adds about three minutes and is environment sensitive,
so keep it opt-in for a sanitizer or nightly job while the functional fixtures
still run on every swift-capable run.

An rpc whose Swift name is handle, serviceName, channel, or defaultCallOptions
would clash with a member the generated provider or client inherits, so fail
codegen with a clear message. Cover the reserved names and nested plus imported
request and response payloads.

# Conflicts:
#	compiler/fory_compiler/tests/test_service_codegen.py
#	docs/compiler/compiler-guide.md
#	integration_tests/grpc_tests/generate_grpc.py

The module used PEP 585 builtin generics in annotations, which Python 3.8
evaluates at import time. Match the compatible syntax now used by cli.py and
the Swift gRPC service generator.

The FDL, proto, and FlatBuffers parsers annotated a return type with a PEP 585
builtin generic. Importing the CLI loads all three eagerly, so foryc raised
TypeError on 3.8 even after the CLI itself was fixed.

fory-compiler declares requires-python >=3.8, but the compiler job runs 3.11, so
annotation syntax newer than the declared floor reached main unnoticed. Import
the CLI on the oldest supported interpreters, which covers every module it
loads eagerly.

The thread-local key held only the generated textual type path, so every
default-package schema produced org.apache.fory.grpc.ForyModule. Two generated
targets in separate Swift modules shared that key, and the second wrapper reused
the first module's Fory without its own registrations. Build the key from
String(reflecting:), which is module-qualified at runtime.

Enum-style packages nest their types under a namespace enum, but that enum is
itself a file-scope declaration. Preflight recorded no symbol for it, so two
schemas sharing a top-level package component passed and Swift then rejected the
duplicate declaration. Record the namespace owner so generation fails first.

The symbol collector returned a set, so a name declared twice by one schema
collapsed to a single entry and preflight reported no collision. Report every
declaration with the Swift scope that contains it, keeping duplicates, so the
generated helper against a same-named message, flattened helper names, and names
that normalize to the same identifier all fail before generation.

The namespace section still described an invalid redeclaration at build time,
but the compiler now rejects a shared root namespace before writing either file,
and the separate-module workaround needs one invocation per module because a
single invocation preflights every schema together. The language mode section
also predated the Sendable payload constraint, which applies to all call
shapes rather than only the streaming client.

Both marshaller regression tests asserted coverage they did not have.

testSeparateModulesKeepOwnRuntimeOnOneThread claimed to guard the module-scoped
ForyRuntime key from d2a47f2, but it used GrpcFdl and GrpcFbs, which compile
into one target and carry packages, so their keys were already distinct under the
old scheme and it stayed green when that scheme was restored. Add two
package-less schemas generated into their own SwiftPM targets: both emit a bare
ForyModule, so their generated key expressions are identical and only runtime
module qualification separates them. Each needs its own foryc invocation, since
one invocation preflights its schemas together and rejects the duplicate
declaration. Against the old "org.apache.fory.grpc.{module}" scheme the new test
fails with "Type not registered: DefaultPackageTwoRequest is not registered".
The old test is renamed to testPackagedSchemasKeepOwnRuntimeOnOneThread, which
is what it actually covers.

The concurrency test claimed to run under ThreadSanitizer in CI, which ran only
plain swift test. The one --sanitize=thread command sat behind FORY_SWIFT_TSAN
in run_tests.sh, which the workflow never invokes and nothing sets. That command
was also broken on macOS rather than merely unreachable: SwiftPM launches XCTest
bundles through the platform-signed swiftpm-xctest-helper and xctest, and dyld
refuses to load the sanitizer runtime into them, while SIP strips
DYLD_INSERT_LIBRARIES. A swift-testing runner is a plain executable and has no
such restriction, so the suite moves to swift-testing and CI runs it with
--sanitize=thread --disable-xctest. Reverting the per-thread Fory to a shared
instance makes TSan report 70 races in TypeResolver.finalizeTypeMeta and exit 1,
so a race fails the step without TSAN_OPTIONS. The step greps for the suite
result so it cannot decay into a zero-test no-op.

Delete FORY_SWIFT_TSAN and its run_tests.sh block: nothing set it, its command
did not work, and CI now owns the sanitized run.

…eholder

from: "1.2.0" advertised a floor that permits releases whose Swift Serializer
lacks Target, and that predate the tracked-value root ref-slot fix needed for
Java/Swift interop.

Naming the first release containing both is not possible yet: df15e7c is in no
tag and is not an ancestor of v1.7.0-rc1, so no cut release carries it and any
concrete number would be a guess. Use the existing convention instead and match
docs/object-serialization/swift/index.md verbatim with exact: "$version".

ci/release.py leaves the placeholder alone because VERSION_PATTERN matches only
numeric versions, and the adjacent grpc-swift line does not match
_is_release_doc_line, so a Fory release cannot rewrite grpc-swift's version.

The in-process round-trip test and the interop client shut down their gRPC and
NIO resources from `defer` blocks using syncShutdownGracefully() and
EventLoopFuture.wait(). Both are unavailable from asynchronous contexts, so the
Java/Swift CI job reported four warnings and the Swift 6 language mode turns the
syncShutdownGracefully() one into an error. wait() on an event loop thread can
also deadlock, which is why NIO marks it unavailable rather than merely noisy.

`defer` cannot await, so the test collects an async teardown step per resource
and unwinds them in reverse on both exit paths, and the client closes its channel
explicitly on the success and failure paths. Teardown behaviour is unchanged:
verified by instrumenting each step and observing channel, server, then group run
when the body succeeds and when it throws.

Our sources now build with zero warnings; the remaining ones come from
third-party checkouts.

Bring the Swift gRPC branch up to date with main, which has moved 28 commits
ahead including the 1.6.1 release version bump.

…workaround

The Swift package tests were gated only on `command -v swift`, so
./run_tests.sh GoGrpcTest resolved and ran them whenever a toolchain was
installed, and the SwiftGrpcTest release build sat in a second block. Both now
share one has_test_class "SwiftGrpcTest" guard, keeping the tool-availability
check before Swift is invoked.

The namespace section also told users that generating into separate Swift modules
with one foryc invocation each works around a shared root namespace. That only
holds for unrelated schemas. validate_swift_files builds its graph through
collect_schema_graph, which walks imports recursively, so compiling demo.greeter
still includes demo.shared and rejects the duplicate Demo even when the shared
schema was generated in another invocation. An import graph needs disjoint
top-level packages, and the section now says so.

safe_member_name routes the rpc name through to_camel_case, which strips
underscores, so an all-underscore name normalizes to empty and safe_identifier
returns its "_" fallback. rpc _, __, and ___ all reached it and emitted func _,
static let _, and Methods._. swiftc rejects func _ outright, while static let _
parses as a wildcard binding and fails only where Methods._ is referenced.

Reject instead of renaming: an invented name would be arbitrary and could collide
on its own. The check joins the existing method-name preflight, which the CLI
reaches before writing any file, so it exits with a clear error and leaves no
partial output. That preflight now covers unusable names, reserved members, and
duplicates, so it is named _check_swift_grpc_method_names.

Document both rpc-name rules, including the reserved-member list that was
already enforced but never written down.

swift_declared_symbols() iterated only the schema's top-level enums, unions, and
messages, so nested declarations never reached the collision preflight. A schema
such as message Parent { message my_type {} message MyType {} } passed and then
emitted two public struct MyType inside Parent. The failure is semantic rather
than syntactic, so swiftc reports invalid redeclaration only at type-check.

Walk nested messages, enums, and unions recursively and key each declaration by
its parent Swift scope. Enums and unions stop the walk because only Message
carries nested collections. Nested names keep the bare normalized form, so the
flatten namespace prefix still applies to the top-level owner alone.

test_swift_nested_normalized_name_collision_fails_preflight described package
namespace nesting rather than an IDL nested type, so it is renamed to
..._packaged_..., and real nested cases now have their own tests, including a
deeper level and same-named types under distinct parents.

…d code

The generated models declare Equatable but not Sendable, and the gRPC wire
wrapper constrains its payload to Sendable, so Swift 6 strict concurrency
rejects every call shape rather than only the streaming ones.

Say so in the model documentation as well, because the limit applies to any
Swift 6 code that moves a generated value across an isolation boundary, not only
to gRPC users. Drop the claim that Swift 6 support follows once models are
Sendable: messages using ref or weak fields generate classes with mutable stored
properties, which cannot declare Sendable at all.